Multi-ring reliable messaging system

ABSTRACT

A multi-ring reliable messaging system is formed by interconnecting a plurality of token rings via a pair of gateways that includes an active gateway that is configured to communicate with the token rings and a standby gateway that also is configured to communicate with the token rings. The active gateway receives an original message via a first token ring, generates an associated message for a second token ring based on the original message, and propagates the associated message toward the second token ring. The active gateway supports total order delivery of messages within the token rings and causal-order delivery of messages between the token rings. The standby gateway monitors for original and associated messages received via the token rings in a manner for preventing loss of messages when the active gateway fails.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 13/803,558, filed on Mar. 14, 2013, entitled MULTI-RING RELIABLE MESSAGING SYSTEM, which is hereby incorporated herein by reference.

TECHNICAL FIELD

The disclosure relates generally to messaging systems and, more specifically but not exclusively, to handling exchanges of messages in messaging systems.

BACKGROUND

In many types of systems, there is a need for system components to rapidly achieve agreement on the current state of the system via message exchanges. In some such systems, message exchanges are provided using message router solutions (e.g., RabbitMQ) or via use of a token-ring protocol (e.g., the Spread Toolkit or the TOTEM protocol as implemented by corosync). Disadvantageously, however, message router solutions typically face bottleneck conditions as system size increases, and token-ring protocols may scale poorly with system size.

SUMMARY OF EMBODIMENTS

Various deficiencies in the prior art may be addressed by embodiments related to a multi-ring reliable messaging capability.

In one embodiment, an apparatus includes a processor and a memory communicatively connected to the processor, where the processor is configured to receive an original message via a first token ring, determine a second token ring to which the original message is to be provided, generate an associated message for the second token ring based on the original message, and propagate the associated message toward the second token ring.

In one embodiment, a method includes using a processor and a memory for receiving an original message via a first token ring, determining a second token ring to which the original message is to be provided, generating an associated message for the second token ring based on the original message, and propagating the associated message toward the second token ring.

In one embodiment, an apparatus includes a processor and a memory communicatively connected to the processor, where the processor is configured to receive an original message from a first token ring, store the original message in the memory, and monitor for receipt of one or more associated messages associated with the original message from, respectively, one or more other token rings.

In one embodiment, a method includes using a processor and a memory for receiving an original message from a first token ring, storing the original message in the memory, and monitoring for receipt of one or more associated messages associated with the original message from, respectively, one or more other token rings.

BRIEF DESCRIPTION OF THE DRAWINGS

The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 depicts an exemplary multi-ring messaging system including a plurality of rings and a pair of gateways including an active gateway and a standby gateway;

FIG. 2 depicts an exemplary embodiment of a method for use by the active gateway of FIG. 1 to handle a message originating from one of the token rings of FIG. 1;

FIG. 3 depicts an exemplary embodiment of a method for use by the standby gateway of FIG. 1 to handle a message originating from one of the token rings of FIG. 1;

FIG. 4 depicts an exemplary embodiment of a method for use by the standby gateway of FIG. 1 to handle messages originating from the token rings of FIG. 1;

FIG. 5 depicts an exemplary embodiment of a multi-ring messaging system for a cloud-based radio access network management application;

FIG. 6 depicts an exemplary message flow for the exemplary multi-ring messaging system of FIG. 5; and

FIG. 7 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION OF EMBODIMENTS

In general, a multi-ring reliable messaging capability is provided herein. In at least some embodiments, the multi-ring reliable messaging capability may support use of a plurality of interconnected token rings to implement a reliable messaging system, referred to herein as a multi-ring reliable messaging system. It will be appreciated that the plurality of token rings interconnected to implement a reliable messaging system may be a subset of the available token rings (e.g., a subset of the token rings in a system in which the multi-ring reliable messaging capability is provided).

In at least some embodiments, a multi-ring reliable messaging system may be formed by interconnecting a plurality of token rings via a pair of gateways that includes an active gateway that is configured to communicate with each of the plurality of token rings and a standby gateway that also is configured to communicate with each of the plurality of token rings. Here, it will be appreciated that the plurality of token rings may be a select plurality of token rings (e.g., a subset of token rings selected from a set of token rings which are or may be used to provide a multi-ring reliable messaging system).

In at least some embodiments, the active gateway is configured to receive an original message via a first token ring of the plurality of token rings and propagate one or more associated messages toward one or more other token rings for which the original message is intended. In at least some embodiments, the active gateway is configured to receive an original message via a first token ring of the plurality of token rings, determine one or more other token rings to which the original message is to be provided, generate one or more associated messages for the one or more other token rings to which the original message is to be provided, and propagate the one or more associated messages toward the one or more other token rings.

In at least some embodiments, the standby gateway is configured to monitor for original and associated messages received via the token rings in a manner for preventing loss of messages when the active gateway fails. In at least some embodiments, the standby gateway is configured to receive, from a first token ring of a plurality of token rings, an original message generated by a node of the first token ring, store the original message, and monitor for receipt of one or more associated messages, associated with the original message, from one or more other token rings of the plurality of token rings.

In at least some embodiments, message delivery within each of the token rings is performed such that total-order message delivery is provided within each of the token rings, but message delivery between the token rings is relaxed such that total-order message delivery does not need to be supported between the token rings (e.g., only supporting causal-order delivery of messages between token rings). In general, it will be appreciated that delivery of messages with total-order means that messages are delivered to each of the intended recipients (as well as the sender of the message) in the same order. In general, it will be appreciated that delivery of messages with causal-order means that if the sending of a message “a” precedes the sending of a message “b” then the delivery of message “a” occurs before the delivery of message “b”.

In at least some embodiments, a multi-ring reliable messaging system is organized such that nodes of the multi-ring reliable messaging system are grouped based on respective node types of the nodes (e.g., for each node type of the nodes of the multi-ring reliable messaging system, the nodes are grouped into one or more token rings for the respective node type). In at least some embodiments, grouping of nodes into the token rings based on node type may be used to ensure that total-order delivery of messages is supported between nodes of the same node type (within the respective token rings) while only causal-order delivery of messages needs to be supported between nodes of different node types (between the token rings). In other words, in at least some embodiments, the multi-ring reliable messaging system may take advantage of the fact that, as system size increases, there is expected to be an associated increase in the likelihood that the system will include groups of nodes that are only interested in subsets of messages generated within the system, such that groups of nodes may be maintained for specific types of messages generated within the system and requirements for total-order delivery of messages across the system may be relaxed such that total-order delivery of messages only may be required within the groups of nodes while causal-order delivery of messages may be supported between the groups of nodes.

In at least some embodiments, a multi-ring reliable messaging system facilitates horizontal scalability while retaining various benefits associated with use of token rings for message delivery (e.g., reliable message delivery, fast reaction times, and the like). It will be appreciated that horizontal scalability overcomes existing limitations of token ring networks in terms of the number of nodes which may be supported (e.g., such as where certain types of token rings may be limited to a maximum of M nodes, and may even be further limited to use of less than M nodes due performance considerations such as message delay and other criteria). For example, in a token ring network limited to M nodes, a multi-ring reliable messaging system including N such token rings may be able to support N×M total nodes (which may be a much larger number of nodes than could otherwise be supported without use of a multi-ring reliable messaging system).

Various embodiments of the multi-ring reliable messaging capability may be better understood by way of reference to an exemplary multi-ring messaging system as depicted and described with respect to FIG. 1.

FIG. 1 depicts an exemplary multi-ring messaging system including a plurality of rings and a pair of gateways including an active gateway and a standby gateway.

The exemplary multi-ring messaging system 100 includes a plurality of token rings 110 ₁-110 _(N) (collectively, token rings 110) and a pair of gateways including an active gateway 120 _(A) and a standby gateway 120 _(S) (collectively, gateways 120). The gateways 120 are each communicatively connected to each of the token rings 110.

The token rings 110 include respective pluralities of nodes 112 ₁-112 _(M) (collectively, nodes 112). Within a given token ring 110, the nodes 112 of the token ring 110 are communicatively connected in a ring architecture. The nodes 112 in the token rings 110 may be organized based on the node types of the nodes 110. In at least some embodiments, the token rings 110 and associated nodes 112 may be organized such that, for N node types to be supported within exemplary multi-ring messaging system 100, nodes 112 having the same node type are grouped together to form the token rings 110 ₁-110 _(N), respectively (namely, nodes 112 ₁ of token ring 110 ₁ are nodes of a first node type, nodes 112 ₂ of token ring 110 ₂ are nodes of a second node type, and so forth). It will be appreciated that, although primarily depicted and described with respect to a one-to-one relationship between nodes types of the nodes 112 and the token rings 110, the token rings 110 and associated nodes 112 may be organized using other arrangements (e.g., multiple node types may be combined within a single token ring 110, nodes of a given node type may be organized into a plurality of token rings 110, or the like, as well as various combinations thereof). It will be appreciated that, in at least some embodiments, nodes 112 of a given node type may only be distributed across multiple token rings 110 if there is not a requirement for total-order delivery of messages to the node 112 of the given node type (e.g., delivery of messages may only be provided in causal-order between nodes 112 of the respective token rings 110 for the node type). Accordingly, it will be appreciated that the numbers of nodes 112 in the token rings 110 may vary across the token rings 110.

The token rings 110 include respective sets of nodes 112. Within a given token ring 110, the nodes 112 of the token ring 110 are configured to generate messages, propagate generated messages to other nodes 112 of the token ring 110, process messages received from other nodes 112 of the token ring 110, forward messages received from other nodes 112 of the token ring 110, and the like. In general, a message generated by a node 112 of a token ring 110 is considered to have originated from that token ring 110 (and may be referred to as an original message of that token ring 110). With a given token ring 110, the nodes 112 of the token ring 110 are configured to support a token ring protocol which facilitates exchanging of messages between the nodes 112 of that token ring 110. For example, each of the nodes 112 of a given token ring 110 may support a single instance of the token ring protocol used for delivery of messages within that token ring 110. Within a given token ring 110, the nodes 112 of the token ring 110 are configured to support total-order delivery of messages within the token ring 110 for messages originating within the token ring 110. The exemplary multi-ring messaging system 100 may support use of one or more token ring protocols supporting total-order message delivery within a token ring (e.g., the TOTEM protocol, the TOTEM protocol as implemented by corosync, the Spread protocol, or any other suitable type of token ring protocol). In at least some embodiments, for example, the same token ring protocol may be used in each of the token rings 110. In at least some embodiments, for example, multiple token ring protocols may be supported such that, while each of the token rings 110 uses one of the multiple token ring protocols, the token ring protocols that are used may vary across the token rings 110.

The token rings 110 also include each of the gateways 120. The gateways 120 each are configured to interface with each of the token rings 110. More specifically, the gateways 120 each are included within the ring architectures of each of the token rings 110, such that each gateway 120 receives each message that is exchanged on each of the token rings 110. In this sense, each gateway 120 appears as a “node” on each token ring 110 (although the presence of the gateways 120 within the token rings 110 may be transparent to the nodes 112 of the token rings 110). The token rings 110 operate independently of each other with the exception of the gateways 120 which integrate the token rings 110 in a manner enabling exchanging of messages between token rings 110. The active gateway 120 _(A) and standby gateway 120 _(S) may be deployed based on anti-affinity rules in order to ensure (or at least increase the likelihood) that both the active gateway 120 _(A) and the standby gateway 120 _(S) do not fail at the same time (e.g., using geographic diversity, platform diversity, or the like).

The active gateway 120 _(A) includes a processor 122 _(A) and a memory 124 _(A) that is communicatively connected to processor 122 _(A). The memory 124 _(A) stores a message exchange program 125 _(A) that, when executed by processor 122 _(A), causes processor 122 _(A) to perform various functions of active gateway 120 _(A) as depicted and described herein. The memory 124 _(A) also may store a data structure 126 _(A) (e.g., a linked list or other suitable type of data structure) which may be used by active gateway 120 _(A) if the active gateway 120 _(A) functions in a standby role after recovering from a failure in which the standby gateway 120 _(S) assumed the role of the active role in response to the failure of the active gateway 120 _(A).

The standby gateway 120 _(S) includes a processor 122 _(S) and a memory 124 _(S) that is communicatively connected to processor 122 _(S). The memory 124 _(S) stores a message exchange program 125 _(S) that, when executed by processor 122 _(S), causes processor 122 _(S) to perform various functions of standby gateway 120 _(S) as depicted and described herein. The memory 124 _(S) also may store a data structure 126 _(S) (e.g., a linked list or other suitable type of data structure) for use in performing various functions of standby gateway 120 _(S) as depicted and described herein.

The processors 122 of the gateways 120 each are configured to interface with each of the token rings 110, where such interfacing may be provided in any suitable manner which may depend on the environment or context within which exemplary multi-ring messaging system 100 is used (e.g., using TCP/IP networking, using one or more communication Application Programming Interfaces (APIs), using N dedicated physical interfaces corresponding to respective token rings 110 ₁-110 _(N), or the like, as well as various combinations thereof). The processors 122 each may be configured to run one or more instances of one or more token ring protocols to support communication with token rings 110 (e.g., depending on the numbers and types of different token ring protocols used by the token rings 110). For example, where each of the token rings 110 is running corosync, each of the processors 122 may be configured to run N instances of corosync for communication by the associated gateways 120 with the respective token rings 110 ₁-110 _(N) (e.g., using N corosync closed process group (CPG) APIs), to run a corosync core that is modified to support multiple simultaneous ring operations on the respective token rings 110 ₁-110 _(N), or the like.

The data structure 126 _(S) of standby gateway 120 _(S) is configured for use in preserving the order of messages for each of the token rings 110. The data structure 126 _(S) may be used to store messages received at standby gateway 120 _(S) from token rings 110 for messages that originate from the token rings 110. The data structure 126 _(S) may be used to track messages received at standby gateway 120 _(S) from token rings 110 for messages that do not originate from the token rings 110 on which the messages are received (i.e., messages generated and provided to the token rings by active gateway 120 _(A)). The data structure 126 _(S) may be implemented as or include a linked list(s) or any other type(s) of data structure(s) suitable for use in storing and tracking messages as discussed above.

Thus, for purposes of clarity, interfacing between the processors 122 of the gateways 120 and the token rings 110 is depicted as respective sets of communication paths between the gateways 120 and the respective token rings 110.

The operation of active gateway 120 _(A) and standby gateway 120 _(S) differs based on their status as being in an active state and a standby state, respectively.

The active gateway 120 _(A) is configured to receive an original message from one of the token rings 110 on which the message originated (as noted above, the message was generated by one of the nodes 112 on that token ring 110).

The active gateway 110 _(A) is configured to propagate the original message via the one of the token rings 110 on which the original message originated, using the token ring protocol of the one of the token rings 110 on which the original message originated, in a manner for maintaining total-order delivery of the original message within the one of the token rings on which the original message originated. It will be appreciated that this is the typical operation of a token ring when a node that is a member of the token ring receives a message generated by another node on the token ring.

The active gateway 120 _(A) also is configured to provide the original message to one or more other token rings 110 to which the original message is to be provided, such that the original message is adequately distributed within exemplary multi-ring messaging system 100. It will be appreciated that references to providing an original message received via one of token rings 110 to one or more other token rings 110 indicates that the information that is conveyed by the original message 110 is to be distributed to other nodes 112 of one or more other token rings 110.

The active gateway 120 _(A) is configured to determine the one or more other token rings 110 to which the original message is to be provided. The one or more other token rings 110 to which the original message is to be provided may include all of the other token rings 110 or a subset of the other token rings 110. The active gateway 120 _(A) may determine the one or more other token rings 110 to which the original message is to be provided based on one or more address fields of the original message, which may be indicative of one or more of a message type of the original message, a node type of the node 112 from which the original message originated, or the like. For example, where exemplary multi-ring messaging system 100 includes four token rings 110 ₁-110 ₄ (i.e., N=4) and an original message originating from a node 112 ₁ of token ring 110 ₁ and received at active gateway 120 _(A) is only of interest to nodes 112 ₂ and nodes 112 ₃ of token rings 110 ₂ and 110 ₃ but is not of interest to nodes 112 ₄ of token ring 110 ₄, the active gateway 120 _(A) only provides the original message to token rings 110 ₂ and 110 ₃ but not to token ring 110 ₄, thereby reducing the number of messages that need to be exchanged within exemplary multi-ring messaging system 100. It will be appreciated that the determination of the other token rings 110 to which the original message is to be provided may not be needed where all original messages generated within each of the token rings 110 are to be distributed to all other token rings 110 (e.g., the active gateway 120 _(A) may simply know that each of the original messages must be fully distributed).

The active gateway 120 _(A) may be configured to provide the original message to the one or more other token rings 110 to which the original message is to be provided using one or more associated messages generated based on the original message. In general, an associated message that corresponds to an original message conveys the same information conveyed by the original message. Thus, the associated message that corresponds to an original message will at least have a payload that includes the same information as the payload of the original message (e.g., in the same format such that the payload of the associated message is identical to the payload of the original message, or in a different format such that the payloads of the associated message and the original message are different but convey the same information) and may even be a duplicate of the original message. For example, where the token rings 110 use different token ring protocols the original message and the one or more associated messages may have identical payloads and different headers. For example, where the token rings 110 use identical token ring protocols and have nodes 112 of the same node type, the one or more associated messages may be identical to the original message. The active gateway 120 _(A) may be configured to generate the one or more associated messages in any suitable manner (e.g., retrieving the original message from memory for each instance of the one or more associated messages to be generated based on the original message, generating one or more copies of the original message and modifying the header information of the one or more associated messages if necessary, or the like, as well as various combinations thereof). Therefore, it will be appreciated that, for purposes of tracking distribution of information within the exemplary multi-ring messaging system 100, there is a distinction between an originating message on a token ring 110 (a message generated by a node 112 of that token ring 110) and an associated message on a token ring 110 (a message generated by the active gateway 120 _(A) for propagation on that token ring 110). It also will be appreciated that the term “messages” may be used when referring to original and associated messages.

The active gateway 120 _(A) may be configured to provide the one or more associated messages to the one or more other token rings 110 to which the original message is to be provided in a manner for maintaining causal-order delivery of the original and associated messages between the token rings 110 for which the original message is intended (namely, the one of the token rings 110 on which the original message is generated and the one or more other token rings 110 for which the original message is intended). The active gateway 120 _(A) does not necessarily need to provide the one or more associated messages to the one or more other token rings 110 in a manner for maintaining total-order delivery of the original and associated message between the token rings 110 for which the original message is intended. It will be appreciated that, since messages are received at active gateway 120 _(A) from the independent token rings 110 in total order within the respective token rings 110, the associated messages will be provided from active gateway 120 _(A) to the token rings 110 in causal order. In at least some embodiments, however, causal-order delivery of messages between the token rings 110 may result in message re-ordering situations in which messages are observed on a token ring 110 in a different order than the order in which they occur on other token rings 110. This type of message re-ordering may or may not be problematic, depending on one or more of the type(s) of messages being delivered, the types of nodes of the token rings 110, the type(s) of token ring protocol(s) of the token rings 110, or the like. For example, total order of state change notification (SCN) messages within a distributed management application may not be required, whereas total order of database update messages within a database system may be required. Accordingly, in at least some embodiments, one or more message re-ordering mechanisms may be used to cope with potential re-ordering of messages between different token rings 110.

An exemplary embodiment of a method which may be executed by processor 122 _(A) of active gateway 120 _(A) is depicted and described with respect to FIG. 2. It will be appreciated that any other combinations of functions depicted and described herein may be implemented as one or more processes configured for execution by processor 122 _(A) of active gateway 120 _(A).

The standby gateway 120 _(S) is configured to ensure that messages are not lost if the active gateway 120 _(A) fails. The standby gateway 120 _(S) receives the same messages that are received by active gateway 120 _(A) (as they are both members of all of the token rings 110), which include original messages that originate on the token rings 110 and associated messages that are generated by the active gateway 120 _(A) and provided to the token rings 110 by the active gateway 120 _(A).

The standby gateway 120 _(S) receives a message from one of the token rings. The standby gateway 120 _(S) determines whether the message is an original message (which originated on the token ring 110 via which the message was received) or an associated message (generated by active gateway 120 _(A) based on an original message that originated on a token ring 110 other than the token ring 110 on which the message was received and was provided to the token ring 110 on which the message was received by active gateway 120 _(A)). The standby gateway 120 _(S) may determine whether the message is an original message or an associated message based on whether or not a version of the message is currently stored on standby gateway 120 _(S) (namely, if a version of the message is not currently stored on standby gateway 120 _(S) then the message is identified as an original message, otherwise the message is identified as an associated message). The determination as to whether a version of the message is currently stored on standby gateway 120 _(S) may be performed based on whether or not a version of the message is stored in memory 124 _(S) of standby gateway 120 _(S).

The standby gateway 120 _(S), in response to receiving an original message via a token ring 110, stores the original message in memory 124 _(S) (e.g., by adding the original message to the data structure 126 _(S)), determines one or more other token rings 110 to which the original message is to be provided (e.g., all of the other token rings 110 or an appropriate subset of the other token rings 110), monitors for receipt of one or more associated messages from the one or more other token rings 110 to which the original message is to be provided, and removes the original message from memory 124 _(S) (e.g., by removing the original message from the data structure 126 _(S)) based on a determination that the one or more associated messages which correspond to the original message have been received at standby gateway 120 _(S) from each of the other token rings 110 to which the original message is to be provided. The standby gateway 120 _(S) may determine the one or more other token rings 110 to which the original message is to be provided in a manner similar to that of the active gateway 120 _(A) (e.g., based on one or more address fields of the message, which may be indicative of one or more of a message type of the message, a node type of the node 112 from which the message originated, or the like). The identification of the one or more other token rings 110 to which the original message is to be provided provides an indication as to one or more other token rings 110 from which the standby gateway 120 _(S) may expect to receive one or more associated messages associated with the original message.

The standby gateway 120 _(S), in response to receiving an associated message via a token ring 110, identifies an original message with which the associated message is associated and updates message tracking information associated with the original message. The message tracking information may include (1) information indicative as to which of the one or more associated messages expected to be received by standby gateway 120 _(S) for the original message have in fact been received by standby gateway 120 _(S) (e.g., a list of the one or more other token rings 110 to which the original message is to be provided is created when the original message is received by standby gateway 120 _(S) and entries are removed from the list as the associated messages are received from the one or more other token rings 110 to which the original message is to be provided) or (2) information indicative as to which of the one or more associated messages expected to be received by standby gateway 120 _(S) for the original message have not yet been received by standby gateway 120 _(S) (e.g., a list of the one or more other token rings 110 to which the original message is to be provided is initialized to be empty when the original message is received by standby gateway 120 _(S) and entries are added to the list as the one or more associated messages are received from the one or more other token rings 110 to which the original message is to be provided). The standby gateway 120 _(S), in response a determination that the original message has been received from each of the one or more other token rings 110 to which the message is expected to be provided (via the one or more associated messages), terminates message tracking for the original message.

In this manner, standby gateway 120 _(S) is able to maintain a snapshot of which of the messages generated within exemplary multi-ring messaging system 100 (namely, original messages generated by nodes 112 of token rings 110 and associated messages generated by the active node 120 _(A)) have been fully distributed within exemplary multi-ring messaging system 100, such that standby gateway 120 _(S) can ensure that messages are not lost if the active gateway 120 _(A) fails.

The standby gateway 120 _(S), based on a determination that active gateway 120 _(A) has failed, determines which associated messages still need to be delivered within exemplary multi-ring messaging system 100 at the time that the active gateway 120 _(A) failed. The standby gateway 120 _(S) may determine which associated messages still need to be delivered by: (1) determining which original messages are still stored in memory 124 _(S), and (2) for each original message still stored in memory 124 _(S): determining which of the one or more other token rings 110 to which the original message is to be provided but via which the standby gateway 120 _(S) has not yet received the associated one or more associated messages from the one or more other token ring(s) 110, and providing one or more associated messages to one or more other token rings 110 to which the original message is to be provided but via which the standby gateway 120 _(S) has not yet received the associated one or more associated messages from the one or more other token ring(s) 110.

The standby gateway 120 _(S) may use the data structure 126 _(S) to support such associated message tracking and distribution functions. For example, the standby gateway 120 _(S) may (1) when an original message is received, add, to the data structure 126 _(S), one or more entries for the one or more other token rings 110 to which the associated one or more associated messages are to be provided (e.g., where the original message is stored x times in the x entries for the x token rings 110 to which the original message is to be provided using x associated message, or where the original message is stored one time for the x entries for the x token rings 110 to which the original message is to be provided and the x entries each include a pointer to the stored original message which is to be provided using x associated message), respectively, and (2) remove the one or more entries from the data structure 126 _(S) as the one or more associated messages associated with the original message are received via the one or more other token rings 110 to which the original message is to be provided. Similarly, for example, the standby gateway 120 _(S) may perform a reverse process of adding entries for the one or more other token rings 110 to which the original message is to be provided as the one or more associated messages associated with the original message are received via the one or more other token rings 110 to which the original message is to be provided. In either case, the standby gateway 120 _(S) is able to monitor and track distribution of associated messages within exemplary multi-ring messaging system 100. It will be appreciated that the data structure 126 _(S) may be implemented as a linked list or using any other type of data structure suitable for use in monitoring for and tracking receipt of associated message from each of the other token ring(s) 110 to which the message is to be provided.

In this manner, standby gateway 120 _(S), by performing such functions for each message originating on each of the token rings 110, is able to ensure that messages are not lost if the active gateway 120 _(A) fails (e.g., for each of one or more original messages for which the active gateway 120 _(A) received the message from the one of the token rings 110 on which the original message originated but failed before providing the original message to each of the one or more other token rings 110 to which the original message is to be provided).

An exemplary embodiment of a method which may be executed by processor 122 _(S) of standby gateway 120 _(S) is depicted and described with respect to FIG. 3. It will be appreciated that any other combinations of functions depicted and described herein may be implemented as one or more processes configured for execution by processor 122 _(S) of standby gateway 120 _(S).

As noted herein, the exemplary multi-ring messaging system 100 may be implemented within various types of environments and contexts and, thus, implementation of various elements of exemplary multi-ring messaging system 100 (e.g., nodes 112, communication between nodes 112 within token rings 110, gateways 120, or the like) may vary with the types of environments and contexts.

In at least some embodiments, for example, exemplary multi-ring messaging system 100 may be used to support an application in a cloud environment. In at least some such embodiments, for example, the nodes 112 may be virtual machines (VMs) hosted within one or more cloud data centers, communication between the nodes 112 within the token rings 110 may be performed using Internet Protocol (IP) based networking, the gateways 120 may be VMs hosted within one or two cloud data centers (e.g., hosted on different hosts within a single data center, hosted in geographically distributed data centers, or the like), and the messages may include state change notifications. In at least some such embodiments, the application may be a carrier grade telecommunications application, a cloud-based file system, an online shopping application, or the like. An exemplary embodiment of a multi-ring messaging system configured to support cloud-based management of a Third Generation Radio Access Network (RAN) is depicted and described with respect to FIGS. 5-6.

In at least some embodiments, for example, exemplary multi-ring messaging system 100 may be used within a server device. In at least some such embodiments, for example, the nodes 112 may be server blades of the server device, communication between the nodes 112 within the token rings 110 may be performed using internal communications buses, the gateways 120 may be dedicated cards of the server device, and the messages may include state change notifications.

In at least some embodiments, for example, exemplary multi-ring messaging system 100 may be used within a database system. In at least some such embodiments, for example, the nodes 112 may be processors responsible for management of respective portions of the database system, communication between the nodes 112 within the token rings 110 may be performed using any suitable types of communication paths (e.g., internal communication paths, networked communication paths, or the like), the gateways 120 may be dedicated processors of the database system, and the messages may include database update instructions.

It will be appreciated that the foregoing examples provide merely a few of the various environments and contexts within which embodiments of the exemplary multi-ring messaging system 100 may be implemented.

FIG. 2 depicts an exemplary embodiment of a method for use by the active gateway of FIG. 1 to handle a message originating from one of the token rings of FIG. 1. It will be appreciated that, although primarily depicted and described as being performed serially, at least a portion of the steps of method 200 may be performed contemporaneously or in a different order than depicted in FIG. 2. At step 201, method 200 begins. At step 210, an original message originating from a token ring is received via the token ring. At step 220, one or more other token rings to which the original message is to be provided are determined. At step 230, one or more associated messages are generated, for the one or more other token rings to which the original message is to be provided, based on the original message (e.g., generating one or more new payloads based on the payload of the original message, including the payload of the original message, as one or more copies of the original message, or the like). At step 240, the one or more associated messages are provided to the one or more other token rings to which the original message is to be provided. At step 299, method 200 ends. It will be appreciated that the operation of method 200 of FIG. 2 may be better understood when read in conjunction with FIG. 1.

FIG. 3 depicts an exemplary embodiment of a method for use by the standby gateway of FIG. 1 to handle a message originating from one of the token rings of FIG. 1. It will be appreciated that, although primarily depicted and described as being performed serially, at least a portion of the steps of method 300 may be performed contemporaneously or in a different order than depicted in FIG. 3.

At step 301, method 300 begins.

At step 310, an original message is received via a token ring on which the original message originated.

At step 320, the original message is stored. The original message is stored for later use in distributing the original message via one or more token rings, if necessary, when an active gateway associated with the standby gateway fails.

At step 330, one or more other token rings to which the original message is to be provided are determined. The one or more other token rings represent the one or more token rings from which the standby gateway expects to receive one or more associated messages to be generated by the active gateway for distributing the information of the original message to the one or more other token rings.

At step 340, monitoring for receipt of the one or more associated messages from the one or more other token rings is performed. The monitoring includes tracking which of the one or more other token rings via which the one or more associated messages have been received. The tracking of which of the one or more other token rings via which the one or more associated messages have been received may be performed using a data structure.

At step 350, the original message is handled based on the monitoring for receipt of the one or more associated messages from the one or more other token rings. If each of the one or more associated messages is received at the standby gateway before an active gateway associated with the standby gateway fails, the original message is removed from the standby gateway and monitoring for the one or more associated messages is terminated. If at least one of the one or more associated messages is not received at the standby gateway before an active gateway associated with the standby gateway fails, the original message is provided to any of the one or more other token rings to which the original message is to be provided but from which the associated message has not been received (e.g., using one or more associated messages associated with the original message, in a manner similar to the active gateway). In this manner, complete and reliable delivery of the original message may be assured even when the active gateway fails.

At step 399, method 300 ends.

FIG. 4 depicts an exemplary embodiment of a method for use by the standby gateway of FIG. 1 to handle messages originating from the token rings of FIG. 1. It will be appreciated that, although primarily depicted and described as being performed serially, at least a portion of the steps of method 400 may be performed contemporaneously or in a different order than depicted in FIG. 4.

At step 401, method 400 begins.

At step 410, messages are received via a plurality of token rings. The messages may include original messages received via the token rings on which the message originate or associated messages received via token rings other than the token rings on which the associated original messages originate (e.g., distributed on the token rings by an active gateway that is associated with the standby gateway).

At step 420, the received messages are tracked. For each original message received via the token ring, tracking for the original message includes determining one or more other token rings to which the original message is to be provided and tracking which of the one or more other token rings to which the original message is to be provided from which the original message (e.g., in the form of one or more associated messages that are generated based on the original message) is received. For each associated message received via the token ring, tracking for the associated message includes identifying the original message with which the associated message is associated and marking that the associated message for that original message has been received via that token ring. In at least some embodiments, tracking of the received messages may be performed using a data structure of the standby gateway.

At step 430, a determination is made as to whether the active gateway has failed. If the active gateway has not failed, method 400 returns to step 410 (i.e., the method 400 continues to operate with the standby gateway continuing to receive messages via the token rings and track the messages received via the token ring). If the active gateway has failed, method 400 proceeds to step 440.

At step 440, a recovery procedure is initiated based on the tracking of the received messages. The recovery procedure includes identifying each original message for which distribution of the original message using one or more associated messages is incomplete (namely, one or more associated messages have not been received via each of the one or more other token rings to which the original message is to be provided) and, for each original message for which distribution of the original message using one or more associated messages is incomplete, providing the original message to one or more other token rings using one or more associated messages in a manner for competing distribution of the original message.

At step 499, method 400 ends.

Various embodiments of the multi-ring reliable messaging capability may be better understood by considering an exemplary embodiment of a multi-ring messaging system for a cloud-based radio access network management application, as depicted and described with respect to FIGS. 5 and 6.

FIG. 5 depicts an exemplary embodiment of a multi-ring messaging system for a cloud-based radio access network management application.

The exemplary multi-ring messaging system 500 supports exchanging of state change notification (SCN) messages related to management of a radio access network (RAN) including a multitude of cell sites providing cellular access for wireless user devices (e.g., a multitude of NodeBs providing cellular access for User Equipments (UEs)). The SCN messages are primarily used to communicate the state of virtual machines (VMs) used to provide a cloud-based implementation of a Radio Network Controller (RNC) of a RAN. The VMs provide specific functions of the RNC, including cell management functions (provided by CMU VMs), user equipment management functions (provided by UMU VMs), and protocol conversion functions (provided by PC VMs). For example, the SCN messages may be messages related to cell site events (e.g., cell sites going down, cell sites coming back up), related to wireless user devices impacted by cell site events, related to backhaul equipment supporting transport of traffic between the cell sites and the wireless core network, or the like.

The exemplary multi-ring messaging system 500 includes three token rings 510 as follows: a CMU token ring 510 ₁ composed of a plurality of CMU nodes 512 ₁ (representing the respective CMU VMs) configured to monitor the status of and control cell sites, a UMU token ring 510 ₂ composed of a plurality of UMU nodes 512 ₂ (representing the respective UMU VMs) configured to monitor and control wireless user devices supported by the cell sites, and a PC token ring 510 ₃ composed of a plurality of PC nodes 512 ₃ (representing the respective PC VMs) configured to act as network gateways isolating the private network within the cloud and the public network hosting the cell sites and core network components. The CMU token ring 510 ₁, UMU token ring 510 ₂, and PC token ring 510 ₃ may be referred to collectively as token rings 510 and, similarly, the CMU nodes 512 ₁, UMU nodes 512 ₂, and PC nodes 510 ₃ may be referred to collectively as nodes 512.

The exemplary multi-ring messaging system 500 also includes an active gateway 520 _(A) and a standby gateway 520 _(S), each of which participates within each of the token rings 510. The active gateway 520 _(A) and a standby gateway 520 _(S) also are implemented using VMs, respectively. The active gateway 520 _(A) and a standby gateway 520 _(S) provide a reliable messaging service across all of the nodes 512 of the token rings 510. For example, exemplary multi-ring messaging system 500 may be configured to operate as depicted and described with respect to exemplary multi-ring messaging system 100. The operation of exemplary multi-ring messaging system 500 may be better understood by considering an exemplary message flow for exemplary multi-ring messaging system 500, as depicted and described with respect to FIG. 6.

FIG. 6 depicts an exemplary message flow for the exemplary multi-ring messaging system of FIG. 5. It will be appreciated that, although primarily depicted and described as being performed serially, at least a portion of the steps of exemplary message flow 600 may be performed contemporaneously or in a different order than depicted in FIG. 6.

As depicted in FIG. 6, each of the elements of FIG. 5 participates in the exemplary message flow (namely, token ring 510 ₁ having CMU nodes (denoted as CMU token ring 510 ₁), token ring 510 ₂ having UMU nodes (denoted as UMU token ring 510 ₂), token ring 510 ₃ having PC nodes (denoted as PC token ring 510 ₃), active gateway 520 _(A), and standby gateway 520 _(S).

At step 602, CMU token ring 510 ₁ sends a message (denoted as C3 DOWN) indicating that node C3 of the CMU token ring 510 ₁ has gone down. The C3 DOWN message is received by both active gateway 520 _(A) and standby gateway 520 _(S).

At step 604, standby gateway 520 _(S) determines that the C3 DOWN message needs to be distributed to both UMU token ring 510 ₂ and PC token ring 510 ₃. The standby gateway 520 _(S) adds to its data structure two entries indicating that the C3 DOWN message needs to be distributed to both UMU token ring 510 ₂ (denoted as entry C3 DOWN->UMU) and PC token ring 510 ₃ (denoted as C3 DOWN->PC).

At step 606, active gateway 520 _(A), based on a determination that the C3 DOWN message needs to be distributed to UMU token ring 510 ₂, propagates the C3 DOWN message to UMU token ring 510 ₂.

At step 608, standby gateway 520 _(S) receives the C3 DOWN message via UMU token ring 510 ₂ and updates its data structure to reflect receipt of the C3 DOWN message via UMU token ring 510 ₂ (illustratively, by removing the C3 DOWN->UMU entry from the data structure, leaving only the C3 DOWN->PC entry in the data structure for the C3 DOWN message).

At step 610, active gateway 520 _(A), based on a determination that the C3 DOWN message also needs to be distributed to PC token ring 510 ₃, propagates the C3 DOWN message to PC token ring 510 ₃.

At step 612, standby gateway 520 _(S) receives the C3 DOWN message via PC token ring 510 ₃ and updates its data structure to reflect receipt of the C3 DOWN message via PC token ring 510 ₃ (illustratively, by removing the C3 DOWN->PC entry from the data structure, such that the data structure no longer includes any entries for the C3 DOWN message).

At step 614, CMU token ring 510 ₁ sends a message (denoted as C3 UP) indicating that node C3 of the CMU token ring 510 ₁ has come back up. The C3 UP message is received by both active gateway 520 _(A) and standby gateway 520 _(S).

At step 616, standby gateway 520 _(S) determines that the C3 UP message needs to be distributed to both UMU token ring 510 ₂ and PC token ring 510 ₃. The standby gateway 520 _(S) adds to its data structure two entries indicating that the C3 UP message needs to be distributed to both UMU token ring 510 ₂ (denoted as entry C3 UP->UMU) and PC token ring 510 ₃ (denoted as C3 UP->PC).

At step 618, active gateway 520 _(A), based on a determination that the C3 UP message needs to be distributed to UMU token ring 510 ₂, propagates the C3 UP message to UMU token ring 510 ₂.

At step 620, standby gateway 520 _(S) receives the C3 UP message via UMU token ring 510 ₂ and updates its data structure to reflect receipt of the C3 UP message via UMU token ring 510 ₂ (illustratively, by removing the C3 UP->UMU entry from the data structure, leaving only the C3 UP->PC entry in the data structure for the C3 UP message).

At step 622, active gateway 520 _(A) fails. At this time, the data structure of standby gateway 520 _(S) still includes the C3 UP->PC entry for the C3 UP message.

At step 624, CMU token ring 510 ₁, UMU token ring 510 ₂, PC token ring 510 ₃, and standby gateway 520 _(S) detect that active gateway 520 _(A) has failed.

At step 626, a gateway switching process is initiated to enable standby gateway 520 _(S) to begin operating as the active gateway for exemplary multi-ring messaging system 500 and to enable active gateway 520 _(A) to begin operating as the spare gateway for exemplary multi-ring messaging system 500 after active gateway 520 _(A) recovers from its failure.

At step 628, standby gateway 520 _(S) initiates a message recovery process based on its data structure, which represents the set of messages which should have been, but were not, propagated by active gateway 520 _(A) before failing. In the exemplary message flow 600, the data structure of standby gateway 520 _(S) still includes the C3 UP->PC entry for the C3 UP message, which indicates to standby gateway 520 _(S) that active gateway 520 _(A) did not propagate the C3 UP message via PC token ring 510 ₃ before failing.

At step 630, standby gateway 520 _(S), based on a determination from its data structure that the C3 UP message still needs to be distributed to PC token ring 510 ₃, propagates the C3 UP message to PC token ring 510 ₃.

At step 632, standby gateway 520 _(S) updates its data structure to reflect propagation of the C3 UP message via PC token ring 510 ₃ (illustratively, by removing the C3 UP->PC entry from the data structure, such that the data structure no longer includes any entries for the C3 DOWN message). As depicted at step 632, the data structure of standby gateway 520 _(S) is now empty (i.e., the message recovery process is complete).

At step 634, standby gateway 520 _(S) sends a message recovery process complete message to active gateway 520 _(A) (which, as noted above, now operates as the spare gateway for exemplary multi-ring messaging system 500). The exemplary multi-ring messaging system 500 then continues to function as depicted and described with respect to steps 602-620, but with the active/spare roles of active gateway 520 _(A) and standby gateway 520 _(S) reversed, so as to support reliable message delivery for the nodes 512 of the exemplary multi-ring messaging system 500.

As described herein, exemplary multi-ring messaging system 500 associated with exemplary message flow 600 may support total-order delivery of messages within the token rings 510 while only supporting causal-order delivery of messages between the token rings 510, which may result in message re-ordering situations in which messages are observed on a token ring 510 in a order that is different than the order in which they occur on other token rings 510. For example, it is possible that the occurrence of an event U1 on UMU token ring 510 ₂ may happen prior to the occurrence of an event P1 on PC token ring 510 ₃, but that the messages reporting events U1 and P1 may be observed on CMU token ring 510 ₁ in the reverse order (namely, P1, U1). While there should be no consequence to this type of re-ordering for the type of messages delivered within exemplary multi-ring messaging system 500 (namely, SCN messages), this type of re-ordering may be problematic for embodiments in which exemplary multi-ring messaging system 100 is implemented within other types of networks, system, environments, or the like. Accordingly, in at least some embodiments, one or more message re-ordering mechanisms may be used to cope with potential re-ordering of messages.

It will be appreciated that references herein to propagating a message toward a token ring may considered to include various actions which may be performed by a device to send the message toward the token ring such that the message is received by the token ring (namely, by one or more nodes of the token ring). Similarly, it will be appreciated that references herein to providing a message toward a token ring may considered to include various actions which may be performed by a device to propagate or send the message toward the token ring such that the message is received by the token ring.

It will be appreciated that use of the multi-ring messaging capability allows most of the benefits of a token-ring protocol (e.g., TOTEM) to apply to a large system (e.g., as compared to existing messaging systems which do not support use of multiple token-rings as depicted and described herein. For example, various embodiments of the multi-ring messaging capability allow an application to benefit from one or more of safe delivery of messages (e.g., either all or none of the nodes receive messages), delivery of messages in casual order (e.g., it is not possible for a node-up notification to precede the casual node-down notification), robustness (e.g., the system continues to provide service in the event of any node failure, including failure of the active gateway via switchover to the standby gateway), continued use of standard best-effort messaging services (e.g., no custom interconnect technology is required), improved performance (e.g., not only are larger systems possible, but use of multiple smaller rings provides significant reductions in message latency as token circulation time is substantially reduced).

It will be appreciated that, although omitted for purposes of clarity, in at least some embodiments a coordination capability is provided to ensure that both of the gateways see the original message on the original token ring on which it was generated and see any duplicate messages on the other token ring(s) on which the original message is distributed. In at least some embodiments, in order to ensure that the standby gateway does not begin populating its data structure with messages prior to establishment of coordination between the active gateway and the standby gateway, a broadcast coordination message is sent by the standby gateway to all of the token rings and, as the standby receives the coordination message on each of the token rings, the standby gateway will begin recording messages received via the token rings, respectively. It will be appreciated that this coordination capability may be used when a standby gateway is initialized or following recovery of a failed gateway (e.g., where the formerly active gateway comes back up and assumes its role as a standby gateway).

It will be appreciated that, although primarily depicted and described with respect to embodiments in which the active gateway is configured to perform one set of functions (active gateway functions) and the standby gateway is configured to perform another set of functions (standby gateway functions), in at least some embodiments both the active gateway and the standby gateway each may be configured to perform active gateway functions and standby gateway functions (e.g., such that the gateways may switch between the active state and the standby state as necessary in order to ensure delivery of messages within and between the token rings to which the gateways are connected).

It will be appreciated that, although primarily depicted and described with respect to embodiments in which a gateway (i.e., active gateway and standby gateway) is a dedicated node that is provided in addition to the nodes of the token rings to which the gateway is connected, in at least some embodiments the functions of a gateway may be provided by any node that is a member of all of the token rings (e.g., an existing node that is a member of all of the token rings).

It will be appreciated that, although primarily depicted and described with respect to embodiments in which the token rings are interconnected by an active gateway and a standby gateway, in at least some embodiments the token rings may be interconnected by only a single (active) gateway and the standby gateway may be omitted. It will be appreciated that, when only a single gateway interconnects the token rings, causal-order delivery of messages between the token rings may still be ensured.

It will be appreciated that, although primarily depicted and described with respect to exemplary embodiments in which each of the token rings of a messaging system are used, a messaging system may include one or more additional rings. Thus, in at least some embodiments, references herein to each of the rings may be considered to be references to a subset of the rings of a messaging system (or, more generally, a subset of a plurality of rings). Similarly, it will be appreciated that, although primarily depicted and described with respect to exemplary embodiments in which various characteristics of a given token ring apply to each of the nodes of the given token ring, one or more groups of nodes of the token ring may include one or more different characteristics.

FIG. 7 depicts a high-level block diagram of a computer suitable for use in performing functions described herein.

The computer 700 includes a processor 702 (e.g., a central processing unit (CPU) or other suitable processor(s)) and a memory 704 (e.g., random access memory (RAM), read only memory (ROM), and the like).

The computer 700 also may include a cooperating module/process 705. The cooperating process 705 can be loaded into memory 704 and executed by the processor 702 to implement functions as discussed herein and, thus, cooperating process 705 (including associated data structures) can be stored on a computer readable storage medium, e.g., RAM memory, magnetic or optical drive or diskette, and the like.

The computer 700 also may include one or more input/output devices 706 (e.g., a user input device (such as a keyboard, a keypad, a mouse, and the like), a user output device (such as a display, a speaker, and the like), an input port, an output port, a receiver, a transmitter, one or more storage devices (e.g., a tape drive, a floppy drive, a hard disk drive, a compact disk drive, and the like), or the like, as well as various combinations thereof).

It will be appreciated that computer 700 depicted in FIG. 7 provides a general architecture and functionality suitable for implementing functional elements described herein or portions of functional elements described herein. For example, computer 700 provides a general architecture and functionality suitable for implementing one of the nodes 112, a portion of one of the nodes 112, active gateway 120 _(A), a portion of active gateway 120 _(A), standby gateway 120 _(S), a portion of standby gateway 120 _(S), or the like.

It will be appreciated that the functions depicted and described herein may be implemented in hardware or a combination of software and hardware, e.g., using a general purpose computer, via execution of software on a general purpose computer so as to provide a special purpose computer, using one or more application specific integrated circuits (ASICs) or any other hardware equivalents, or the like, as well as various combinations thereof.

It will be appreciated that at least some of the method steps discussed herein may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various method steps. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods or techniques described herein are invoked or otherwise provided. Instructions for invoking the inventive methods may be stored in fixed or removable media, transmitted via a data stream in a broadcast or other signal bearing medium, or stored within a memory within a computing device operating according to the instructions.

It will be appreciated that the term “or” as used herein refers to a non-exclusive “or” unless otherwise indicated (e.g., “or else” or “or in the alternative”).

It will be appreciated that, while the foregoing is directed to various embodiments of features present herein, other and further embodiments may be devised without departing from the basic scope thereof. 

What is claimed is:
 1. An apparatus, comprising: a processor and a memory communicatively connected to the processor, the processor configured to support communication via a set of token rings including a first token ring and a second token ring, the first token ring comprising a first set of nodes of a first node type and the second token ring comprising a second set of nodes of a second node type, the processor configured to: receive an original message via the first token ring; determine, based on the first node type and the second node type, that the original message is to be provided to the second token ring; generate an associated message for the second token ring based on the original message; and propagate the associated message toward the second token ring.
 2. The apparatus of claim 1, wherein the processor is configured to communicate with the first token ring using a first token ring protocol, wherein the processor is configured to communicate with the second token ring using the first token ring protocol or a second token ring protocol.
 3. The apparatus of claim 1, wherein the processor is configured to determine that the original message is to be provided to the second token ring based on a message type of the original message.
 4. The apparatus of claim 1, wherein the processor is configured to support total-order delivery of the original message within the first token ring.
 5. The apparatus of claim 1, wherein the processor is configured to support causal-order delivery of the associated message between the first token ring and the second token ring.
 6. The apparatus of claim 1, wherein the original message comprises a set of information for distribution within the first token ring, wherein the associated message comprises the set of information of the original message.
 7. The apparatus of claim 1, wherein the original message comprises header information, wherein, to generate the associated message, the processor is configured to: copy the original message without modifying the header information.
 8. The apparatus of claim 1, wherein the original message comprises header information, wherein, to generate the associated message, the processor is configured to: copy the original message and modify at least a portion of the header information.
 9. The apparatus of claim 1, wherein the processor is configured to support communication via the token rings using at least one of network communications, one or more communication Application Programming Interfaces (APIs), or one or more physical interfaces to one or more of the token rings.
 10. The apparatus of claim 1, wherein the original message comprises a state change notification (SCN) message related to management of a radio access network (RAN).
 11. A method, comprising: controlling, by a processor, communication via a set of token rings including a first token ring and a second token ring, the first token ring comprising a first set of nodes of a first node type and the second token ring comprising a second set of nodes of a second node type, wherein controlling communication comprises: receiving an original message via the first token ring; determining, based on the first node type and the second node type, that the original message is to be provided to the second token ring; generating an associated message for the second token ring based on the original message; and propagating the associated message toward the second token ring.
 12. The method of claim 11, wherein communication with the first token ring uses a first token ring protocol, wherein communication with the second token ring uses the first token ring protocol or a second token ring protocol.
 13. The method of claim 11, wherein determining that the original message is to be provided to the second token ring is further based on a message type of the original message.
 14. The method of claim 11, wherein controlling communication comprises supporting total-order delivery of the original message within the first token ring.
 15. The method of claim 11, wherein controlling communication comprises supporting causal-order delivery of the associated message between the first token ring and the second token ring.
 16. The method of claim 11, wherein the original message comprises a set of information for distribution within the first token ring, wherein the associated message comprises the set of information of the original message.
 17. The method of claim 11, wherein the original message comprises header information, wherein generating the associated message comprises: copying the original message without modifying the header information.
 18. The method of claim 11, wherein the original message comprises header information, wherein generating the associated message comprises: copying the original message and modifying at least a portion of the header information.
 19. The method of claim 11, wherein communication via the token rings is supported using at least one of network communications, one or more communication Application Programming Interfaces (APIs), or one or more physical interfaces to one or more of the token rings.
 20. The method of claim 11, wherein the original message comprises a state change notification (SCN) message related to management of a radio access network (RAN).
 21. An apparatus, comprising: a processor and a memory communicatively connected to the processor, the processor configured to: receive, at a first node via a first token ring, an original message; monitor, at the first node, a second token ring for receipt of an associated message that is associated with the original message; detect, at the first node, a failure of a second node; determine, at the first node based on detection of the failure of the second node, whether the associated message has been received by the first node via the second token ring; and provide, by the first node based on a determination that the associated message has not been received by the first node via the second token ring, the original message to the second token ring. 